\setcounter{section}{0}

\section{Introducció de conceptes}

Abans de començar amb l'estudi tecnològic pròpiament dit, i per clarificar alguns dels objectius del projecte, veig la necessitat d'introduir alguns conceptes recurrents al llarg del present document.

% a bit of CARTOGRAPHY GIS
\subsection{Els Sistemes GIS}

El contingut d'aquest projecte esta íntimament relacionat amb el concepte de GIS. Així que sembla oportú començar definint breument què s'entén per aquest acrònim i com l'aplicarem en la present memòria.

\paragraph{}

GIS són les sigles en anglès de sistema d'informació geogràfic (geographic information system), i fa referència als sistemes (informàtics o no) dissenyats per adquirir, emmagatzemar, tractar, analitzar i mostrar qualsevol tipus de dades geogràfiques.

\paragraph{}

Cal tenir present la distinció entre els termes cartografia i GIS, ja que GIS és un terme més ampli que implica no només la cartografia sinó també altres ciències com la estadística, i algun tipus d'emmagatzematge de les dades, i per tant esta vinculat molt prominentment amb la tecnologia que fa possible la implementació del sistema.

\paragraph{}

Es considera que el primer sistema GIS data de l'any 1854 (el mapa del brot de colera al barri del Soho de Londres fet per John Snow). Això significa que el terme no te perquè implicar necessàriament la presència de tecnologia informàtica per ser aplicat.

Però avui en dia la informàtica i el GIS estan tan íntimament relacionats que semblen gairebé inseparables. Així que al llarg d'aquest treball sempre que es mencioni el terme GIS se sobreentendrà que es tracta d'un sistema informàtic.

\paragraph{}

Els sistemes GIS tenìen inicialment uns usos importants, però normalment de caire governamental o corporatiu, i no tothom podia accedir a les utilitats d'un sistema GIS. 

\paragraph{}

Per exemple, un dels primers sistemes GIS operacionals com l'entenem avui en dia, que es va desenvolupar al Canadà, servia per monitoritzar els tipus de terra, agricultura, massa forestal, etc. i determinar la capacitat rural del país.

\paragraph{}

Però en els darrers temps, i sobretot gràcies a ``l'obertura'' de la tecnologia de posicionament global (GPS) per a usos personals els sistemes GIS s'han obert a un públic més ampli, i no es d'estranyar que la majoria de la gent porti alguna mena de sistema GIS a la butxaca en aquests moments.

\paragraph{}

Aquest projecte centra bona part dels esforços en el tema de visualització de mapes, però és important tenir present que aquesta només és una part dels sistemes GIS. Naturalment, però, els mapes en són una part molt important.

\paragraph{}
Existeixen diversos proveïdors de mapes (o dades geogràfiques) pels sistemes GIS, i en aquest projecte treballarem amb OpenStreetMap.

% a bit of OSM
\subsubsection{OpenStreetMap}

Un dels proveïdors de mapes més popular actualment és el Google, amb el seu Google maps. També hi han molts altres proveïdors de serveis similars, però majoritàriament aquests serveis no són lliures (tot i que a vegades sí gratuïts).

\paragraph{}

Aquest fet posa de manifest una realitat, que és que la informació geogràfica no és lliure en moltes parts del planeta. A vegades esta controlada per agències governamentals o fins i tot empreses privades que es lucren permetent l'us d'aquestes dades. 

\paragraph{}

Molts cops existeix la il·lusió que aquestes dades són lliures per ser gratuïtes, o que realment si que són lliures, ja que en algunes ocasions fins i tot és possible que les dades crues en sí siguin de domini públic, però que el tractament i presentació d'aquestes no ho sigui.

En el cas particular de Google es pot comprovar a què ens referim si us adreceu als seus termes de servei\cite{bib-google-maps-terms}. 

\paragraph{}

Deixant de banda els aspectes morals de que la informació estigui controlada per certes persones i s'aprofitin d'aquest control per lucrar-se, el cert és que el mateix fet que les dades siguin controlades per interessos comercials és un perill per la mateixa integritat i veracitat d'aquestes.

\paragraph{}

Per posar un exemple pràctic, a vegades les dades que proporcionen aquests serveis de mapes comercials contenen petites inconsistències posades expressament per detectar-ne l'us de persones no autoritzades (el que els d'OpenStreetMap anomenen ``Copyright Easter Eggs'').

\paragraph{}

Això significa incorreccions, o altrament dit dades invàlides. A més de les incorreccions que hi pugui haver per manca d'actualitzacions (que la empresa o agència governamental s'ha d'encarregar d'anar fent) o per errors diversos.

\paragraph{}

A tot això es sumen restriccions d'us d'allò més variades que s'apliquen sobre les dades per temes de copyright, que condicionen què pots fer o deixar de fer amb les dades que proveeixen. A vegades això significa que el que pots fer amb les dades és limitar-te a observar-les.

\paragraph{}
 
Normalment no es pot corregir el nom d'algun carrer, ni Afegir establiments o llocs d'interès o descarregar-te les dades per fer-les servir en el teu ordinador personal per a qualsevol cosa (almenys no lliurement).

\paragraph{}

I a més, quan les dades són propietat d'algú altre, sempre existeix el risc de que en un futur els termes de servei canviïn i apliquin noves i divertides restriccions que converteixin en il·legal alguna pràctica que fins ara realitzaves assíduament.

\paragraph{}

La idea d'OpenStreenMap és aprofitar els avenços tecnològics (Internet i el GPS) per permetre a la gent crear els seus propis mapes i, col·laborant amb gent d'arreu del món crear un servei que proporcioni mapes a tothom sense les restriccions abans mencionades. És a dir, un servei de mapes col·laboratiu i lliure.

\paragraph{}

Actualment el projecte OpenStreetMap està emparat per una fundació sense anim de lucre basada al regne unit anomenada OpenStreetMap Foundation. 

\paragraph{}

Tal i com ells mateixos la defineixen:

\textit{La Fundació OpenStreetMap és una organització sense ànim de lucre dedicada a impulsar el creixement, el desenvolupament i la distribució de dades geoespacials lliures i a proporcionar dades geoespacials per l'ús i la compartició de tothom.}

Els objectius de la fundació són:

\begin{itemize}
\item Custodiar els servidors i els serveis necessaris per mantenir el projecte OpenStreetMap. Concretament gestiona els servidors emplaçats a UCL (University College London) i el domini \url{www.openstreetmap.org}.
\item Protegir el projecte en la mesura del possible d'atacs legals relacionats amb temes de copyright.
\item Adquirir els fons necessaris per mantenir el projecte.
\end{itemize}

Però la fundació no és en cap manera propietària de les dades.

\paragraph{}

A més de la ``base de dades geogràfica'', i la plataforma per contribuir-hi OpenStreetMap també ha aportat formats de transmissió de les seves dades geogràfiques. Un d'aquests formats és una gramàtica de XML anomenada osm, que serveix per fer transaccions de les dades d'OpenStreetMap per la xarxa. També existeix el format binari pbf (``Protocolbuffer Binary Format'') que aporta més compressió, i facilitat d'ús. 

\paragraph{}

OpenStreetMap treballa i transmet la major part de les dades geogràfiques de que disposa en aquests formats, però aquests no són els únics llenguatges de descripció geogràfica. N'existeixen d'altres com el GML i el KML que a continuació es descriuran.

% a bit of GML
\subsubsection{Geography Markup Language}

Geography Markup Language (GML) és una gramàtica de XML (descrita amb un XML Schema) definida per l'Open Geospatial Consortium (OGC) per expressar característiques geogràfiques. El seu objectiu és permetre tant emmagatzemar com comunicar i representar aquestes dades. Cal notar que aquestes característiques (una mala traducció de features) són molt abstractes i generals i permeten modelitzar tota mena d'informació geogràfica, com ara característiques vectorials (com carreteres o vies de ferrocarril), dades topològiques, imatges de terreny o fins i tot dades de sensors com pluviòmetres, etc.

Aquesta propietat d'integrar i aglomerar tot tipus de informació geogràfica és molt important per definir la raó de ser de GML.

Així doncs un dels motius més importants de la seva existència és proporcionar una ``lingua franca'' entre els diferents sistemes GIS existents, per tal que es pogués transportar informació d'un sistema a l'altre de manera més organitzada.

Cal notar també que GML no defineix explícitament \emph{com} s'han de visualitzar les seves dades.

\paragraph{}

Com amb la majoria de gramàtiques basades en XML, GML consta de dos parts, un esquema (XML schema) que descriu el document i un document ``instància'' que conté les dades pròpiament dites. 

El fet que un document GML sigui descrit per un XML schema permet als usuaris i als desenvolupadors descriure en els documents dades geogràfiques genèriques, com ara punts, línies o polígons, però també permet definir extensions del llenguatge per aplicacions més especifiques que defineixin conceptes no tant genèrics com ara un edifici, una carretera, etc.\cite{bib-gml-schema}.

Així, fent servir aquests esquemes més específics també es podran entendre i comunicar mitjançant GML els desenvolupadors de diferents comunitats o sectors concrets.

\paragraph{}

La ``universalitat'' d'aquest llenguatge i el fet que sigui un estàndard molt utilitzat justifiquen els esforços per a intentar incloure'l en el projecte actual.

\paragraph{}

A l'\hyperlink{annex-gml-file}{annex} podeu trobar alguns exemples de fitxers GML.

% a bit of KML
\subsubsection{Keyhole Markup Language}

\hypertarget{estudi-kml}{}Keyhole Markup Language és un llenguatge dissenyat per Keyhole Inc. per a la representació i visualització de mapes bidimensionals o tridimensionals.

\paragraph{}

Esta basat en XML i des de l'abril de 2008 és un estàndard de l'OGC (Open Geospatial Consortium)\cite{bib-kml-schema} cosa que el ratifica com a estàndard obert per a tots els geo-navegadors.

\paragraph{}

La seva popularitat rau en el fet que a l'any 2004 Google va comprar Keyhole Inc. i el seu visualitzador es va convertir en el conegut Google Earth.

Google maps també treballa amb el format KML, i així es va convertir ràpidament en un estàndard \emph{de facto} per a la transmissió i representació de mapes per Internet.

\paragraph{}

La seva estructura és relativament similar a la de GML. Els fitxers KML especifiquen un conjunt de ``features'' (marques de llocs, imatges, polígons, models tridimensionals, descripcions textuals, etc.) per a ser visualitzats.

\paragraph{}

Cadascun d'aquests elements determina una longitud i una latitud, però també es dona la possibilitat d'afegir dades addicionals com ara ``tilt'' (inclinació), ``heading'' (rotació), altitud, etc. que defineixen una ``posició de la càmera''.

\paragraph{}

Un fitxer KML també pot contenir referències a dades addicionals no autocontingudes (per exemple un model tridimensional o una imatge). Això fa que sigui habitual trobar ``publicacions'' de paquets KML comprimits, anomenats KMZ. Això sovint no es fa només per guanyar compressió de dades, sinó per empaquetar tots aquests diversos fitxers addicionals i poder-los distribuir millor. KML també permet referenciar dades remotes que necessitin connexió a la xarxa.

\paragraph{}

El fet que permeti tantes capacitats fa que es tracti d'un llenguatge molt potent per a la representació de mapes. I també fa que algunes d'aquestes dades siguin obviades per a alguns clients, per exemple les dades 3D no solen ser considerades per clients que se centren exclusivament en informació de mapes cartogràfics, o que estan pensats per funcionar en dispositius de baix rendiment, com ara telèfons mòbils Android (que es el nostre cas).

\paragraph{}

A l'\hyperlink{annex-kml-file}{annex} es poden veure alguns exemples de fitxers KML.

% a bit of Android
\subsection{Breu introducció a Android}

\paragraph{}

Android és un sistema operatiu per a dispositius mòbils (smartphones i tablets) basat en Linux. El projecte va ser iniciat per la empresa Android Inc, i actualment esta essent desenvolupat per la ``Open Handset Alliance'', liderada per Google, però de la qual unes altres 86 companyies (principalment fabricants de hardware) també en formen part.

\paragraph{}

Google publica part del codi d'Android sota la Llicència Apache, i per tant alguns l'etiqueten com a software-lliure, tot i que només es cert que ho és parcialment.

\paragraph{}

Al contrari del que passa amb altres sistemes operatius per a smartphones les aplicacions desenvolupades per a Android no han de ser validades per a la companyia que desenvolupa el sistema operatiu, i existeixen diversos canals de publicació d'aplicacions no centralitzats. Tot i que si que és cert que existeix un centre de distribució gestionat per Google, que és el que anteriorment s'anomenava Android Market i que ara es diu Google Play. 

Una particularitat interessant relacionada amb la validació d'aplicacions, és que l'aplicació d'Android està molt controlada pel sistema operatiu. Per aconseguir aquest control les aplicacions requereixen de l'existència d'un document XML anomenat manifest, que declari les ``intencions de l'aplicació''. Això permet a l'usuari que la instal·la saber a quins serveis tindrà accés i decidir si vol instal·lar-la o no. O sigui que malgrat la manca de validació d'aplicacions per part de Google el sistema no està exempt de certs mecanismes de control.

\paragraph{}
Com es pot entreveure la filosofia d'una aplicació d'Android difereix lleugerament de la dels programes de software convencionals. A part de l'existència del manifest i l'execució ``més controlada'', el cicle de vida de les aplicacions també és ``particular'', i esta principalment condicionat per les característiques dels dispositius on s'executa, que tenen una funcionalitat principal de telèfon, bateria limitada, interfície tàctil, etc. 

\paragraph{}
Un programa d'Android consta d'\emph{Activities}, que es poden entendre com a ``pantalles'' que l'usuari veu i \emph{Services} que són processos que no té perquè veure (poden córrer en segon pla).  En primer lloc, les \emph{Activities} estan pensades per poder ser ``pausades'' en qualsevol moment (per exemple si entra una trucada) i més endavant recuperar-ne l'execució, però sense necessitat de que el procés estigui actiu o consumeixi. Així que no s'espera que les aplicacions siguin ``matades'' o finalitzades mai, sinó que s'espera que el sistema s'encarregui de la gestió completa de la vida de l'aplicació.

\paragraph{}
Un conjunt d'Activities poden comunicar-se i cridar-se entre elles mitjançant \emph{Intents}, que són objectes contenidors de dades per a la comunicació. 

De en la mateixa manera a través d'Intents es pot controlar l'execució de \emph{Services} en segon terme si és necessari. Aquest conjunt d'Activities, Services i Intents és el que normalment conforma una aplicació d'Android.

\paragraph{}
Aquestes i d'altres particularitats fa que, en comptes del terme ``programes'' s'utilitzi ``aplicacions'' al llarg de tota la memòria, això és així per emfatitzar aquesta subtil diferència de visió.

\paragraph{}

Cap a finals de 2011, hi havien més de 500,000 aplicacions disponibles per a Android.

\paragraph{}

Sigui per aquests motius o per alguns d'altres, el fet és que actualment Android és el sistema operatiu de mòbil amb més creixement amb diferència. 

Es calcula que el primer trimestre del 2012, Android controlava un 59\% del mercat mundial de smartphones, amb 331 milions de dispositius utilitzant-lo.

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/World-Wide-Smartphone-Sales-Share.eps}
        \caption{Percentatge de vendes de ``smartphones'' (font wikipedia).}\label{fig-world-wide-smatphone-sales-share}
\end{figure}

A part d'aquestes impressionants dades, i de la vinculació de Android amb el món del software Open Source, la vinculació del present projecte amb el ZamiaDroid també ha condicionat l'elecció d'aquest sistema operatiu.


% introducció a zamia i a les millores que proveirà aquest PFC
\subsection{ZamiaDroid}

\paragraph{}
El projecte \textit{Sistema GIS per a la gestió d'espais naturals amb dispositius mòbils} (que ha esdevingut ZamiaDroid o Zamia, per simplificar) és un projecte sorgit de la mateixa facultat d'informàtica de Barcelona, realitzat l'any 2010 per David Martí Pino.

Els objectius principals del projecte eren inicialment de desenvolupar una aplicació per a dispositius mòbils per a la recopilació i gestió d'informació geogràfica d'estudis científics, a més de desenvolupar un servidor web per emmagatzemar les mostres científiques rebudes dels dispositius mòbils.

\paragraph{}
Un cop finalitzat el PFC el projecte va continuar desenvolupant-se (amb notables variacions sobre el plantejament original) en col·laboració amb departament de Biologia de la Universitat de Barcelona.

\paragraph{}
Zamia es el nom que ha adquirit l'aplicació de recol·lecció i gestió de dades geo-referenciades per a dispositius Android del projecte. I malgrat que el servidor de mostres continua existint la major par de la rellevància de tot projecte és actualment aquesta aplicació, així que a partir d'ara sempre em referiré a Zamia o ZamiaDroid al parlar d'aquest projecte.

Cal notar doncs, que el projecte Zamia es un projecte viu, en constant desenvolupament i utilitzat en aplicacions pràctiques per a la comunitat científica i per a qualsevol que el vulgui usar (ja que aquesta aplicació es troba a disposició de tothom).

\paragraph{}
Com molts PFCs, però, Zamia tenia certes ampliacions i millores proposades quan es va realitzar, algunes d'elles han estat implementades en aquests anys, d'altres han esdevingut obsoletes o impracticables degut als canvis d'orientació del projecte, i algunes millores o ampliacions romanen encara per implementar.

\paragraph{}
El present projecte pretén implementar algunes d'aquestes millores i suplir així algunes de les mancances de Zamia, o estendre'n les funcionalitats.

\paragraph{}
A continuació cito un extracte de l'apartat de \textit{Futures ampliacions i millores}  que es pot trobar a la memòria del PFC (que ha esdevingut ZamiaDroid).

\paragraph{}
\textit{Tot seguit es descriuran les possibles millores que es poden introduir al nostre sistema. Aquestes millores no han estat implementades per manca de temps [..]. S'intentaran dur a terme quan el projecte hagi finalitzat.}

[..]

\textit{Millores}
\begin{enumerate} 
\item{}
        \textit{Possibilitat de capturar mostres de figures que són representades per línies o polígons. Ens permetria el càlcul posterior d'àrees o longituds.}
\item{}
        \textit{Possibilitat de correcció de la posició de les mostres sobre mapes. Si es pren una mostra i es veu que l'error del GPS ha estat massa alt es pot donar la possibilitat de canviar la posició de la mostra a un altre indret del mapa.}
\end{enumerate}

A part d'aquestes millores i ampliacions proposades a la memòria del PFC, la resta d'altres objectius del present projecte també responen a una voluntat d'ampliar i millorar el Zamia, com ara la utilització de OpenStreetMap, que permetria prescindir del mapes de Google que ara utilitza l'aplicació, o les funcionalitats fora de línia, etc. I han estat definits amb connivència dels responsables de ZamiaDroid\cite{bib-zamia}.

\subsection{Erdapfel}

\paragraph{}
Erdapfel és el nom amb el qual he batejat l'aplicació autònoma de demostració de les funcionalitats de la biblioteca (i el nom que faré servir d'ara en endavant per referir m'hi).

\paragraph{}
Es tracta d'una aplicació d'Android desenvolupada íntegrament en Java que permet visualitzar mapes de diversos orígens al dispositiu on s'executa, així com generar noves dades, realitzar càlculs simples sobre els mapes i gestionar els mapes ``offline'' locals del dispositiu.

Tot i que inicialment aquesta aplicació de demostració havia de ser molt menys rellevant en el projecte, i només havia de mostrar que les funcions implementades en les biblioteques eren operatives, ha acabat guanyant importància ja que la major part de la integració amb el projecte Zamia en fa ús.

Així doncs, tot i que l'objectiu d'erdapfel continua essent demostrar les capacitats de les biblioteques de mapes implementades, en realitat també realitza la funció d'ampliar les capacitats de Zamia (o qualsevol altre aplicació que en faci us) de manera senzilla.

Més endavant s'explicaran els motius d'haver acabat utilitzant erdapfel per gestionar i coordinar aquesta integració amb Zamia, i no algun altre mitjà.

\paragraph{}
Com a curiositat, he triat el mot erdapfel per batejar el programa, ja que em va semblar un nom atractiu i a l'hora rellevant en l'àmbit cartogràfic. 

Prové de l'alemany, i la seva traducció literal seria ``poma de la terra'' o ``poma del món''. Vaig pensar que seria un nom idoni, ja que és el nom d'una famosa bola del món. De fet, es el nom amb el que es coneix el globus terraqüi més antic preservat actualment. Va ser fabricat per Martin Behaim al 1492, i, per tant, el continent americà encara no hi és present, cosa que no deixa de ser divertida.

\section{Introducció a l'estudi tecnològic}

La cartografia és un camp amb un llarg recorregut en els mitjans informàtics, i les capacitats GPS dels dispositius mòbils els han fet especialment atractius i propicis al desenvolupament d'aquesta ciència.

Així que no es d'estranyar que existeixin moltes alternatives per permetre mostrar i interactuar amb mapes cartogràfics per als dispositius mòbils. I menys encara si tenim en compte que Google, empresa que ha desenvolupat el sistema Android, també ha dedicat una part important dels seus recursos a desenvolupar aplicacions de mapes, i que una de les funcionalitats de Google més populars és el maps.

Però a part de les pròpies solucions de Google moltes d'altres han aparegut. Algunes basades en els mapes de Google i d'altres en alternatives lliures com OpenStreetMap.

\paragraph{}

El següent estudi pretén valorar algunes d'aquestes alternatives existents, tant aplicacions com biblioteques de mapes. Tenint sempre present des d'un bon començament que la nostra proposta havia de complir els \hyperlink{objs}{objectius} marcats anteriorment i per tant havia de ser software lliure, no s'ha estudiat cap tecnologia existent de software privatiu. 

Això ha exclòs un bon nombre de possibilitats, però tot i així el nombre de solucions analitzades és considerable, tal i com es podrà veure a continuació.

\paragraph{}

A més d'estudiar solucions de mapes, també s'ha dedicat part de l'esforça a estudiar la plataforma Android, i més concretament a estudiar la possibilitat de treballar-hi amb llenguatges de programació alternatius a Java (concretament Python).

\section{Aplicacions existents i solucions que utilitzen}

A continuació segueix un estudi a nivell funcional d'algunes aplicacions de mapes existents.

Malgrat que no s'ha pogut trobar cap aplicació que satisfés tots els nostres objectius, cadascuna de les aplicacions analitzades ha aportat valuosa informació que més endavant ha servit per confeccionar el producte resultant d'aquest PFC.

Com podreu comprovar no s'han valorat tan sols aplicacions d'Android, sinó que també s'han valorat algunes aplicacions d'escriptori. Això ha estat degut a que, d'haver cobert els objectius del projecte, s'hauria plantejat la possibilitat de portar-les a Android.

\subsection{ZamiaDroid}

ZamiaDroid és una aplicació de gestió de projectes GIS que ha estat alhora inspiració i punt de partida del present projecte. És l'aplicació que ha de fer un ús més directe de les capacitats de la biblioteca, així que per estudiar-la es volen valorar les seves ``limitacions'' o coses a millorar, però també es vol entendre la filosofa de l'aplicació i la raó de ser de les seves funcionalitats per no obstruir-ne el bon us futur.

\paragraph{}
La visió que mostro en aquest estudi és a nivell purament funcional, però tenint en compte que he pogut estudiar l'aplicació des d'una posició privilegiada, ja que he pogut debatre'n les característiques i la evolució amb el seu creador i principal desenvolupador, i també considerant que la integració amb ZamiaDroid és un dels objectius del projecte, l'estudi resultant és més extens que el de la resta de solucions observades.

\paragraph{}
Com s'ha dit a l'apartat introductori l'aplicació ZamiaDroid sorgeix d'un PFC i evoluciona des dels primers estadis podríem dir-ne acadèmics més genèrics, a l'aplicació força més definida que és avui en dia. Aquesta evolució ha estat constant i a vegades sobtada i/o precipitada, fruit de les necessitats dels projectes o estudis científics que havia d'ajudar a portar a terme.

\paragraph{}
Ara mateix ZamiaDroid permet a grans trets:

\begin{itemize}
        \item Crear i gestionar projectes
        \item Prendre Citacions
        \item Editar Citacions
        \item Veure Citacions sobre un mapa
        \item Veure fotografies de citacions com a galeria
\end{itemize}

\paragraph{}
La creació i gestió de projectes és una funcionalitat important dins del ZamiaDroid, però no te relació directa amb el camp concret que el present projecte pretenen tocar (visualització i edició de mapes cartogràfics). 

\paragraph{}
Un projecte de ZamiaDroid és una unitat lògica per agrupar dades d'estudis científics i és molt versàtil. Però a grans trets, i per les finalitats d'aquest estudi, entendrem un projecte del ZamiaDroid com la definició de formulari d'un estudi científic concret, és a dir, d'una especificació de quins camps han de tenir les mostres de l'estudi que prendrem.

\paragraph{}
Una citació, en l'àmbit de ZamiaDroid, és una d'aquestes mostres. Una instància concreta d'aquests camps o formulari. I a més de les dades definides per l'usuari al crear el projecte (que poden ser una gran varietat de camps i informació de molts tipus) pot contenir informació geogràfica (de fet, aquesta és una de les dades més importants de la citació).

Les citacions es prenen omplint un formulari amb camps definits per l'usuari que poden ser textos, fotografies, etc. i en el moment de prendre-les es te l'opció de que mitjançant el GPS del dispositiu s'incorporin les dades geogràfiques de la ubicació física on ens trobem automàticament.

Això vol dir que en un cas d'us usual del Zamia no fa falta visualitzar un mapa i ubicar les citacions en ell, sinó que simplement es prenen les dades de la mostra (qualsevulla que siguin aquestes) i la citació queda enregistrada amb les dades geogràfiques pertinents.

Evidentment, després aquestes dades poden ser ``pintades'' a sobre d'un mapa i l'usuari de Zamia les pot observar i fins i tot modificar des d'allà.

De fet hi han diversos casos d'us per generar citacions. Per exemple des de la mateixa pantalla de ``veure citacions'' es poden crear també noves citacions, i editar les existents. Però al capdavall el que ens interessa és que existeix la possibilitat de mostrar les dades sobre un mapa, i que aquest mapa és proporcionat per GoogleMaps.

\paragraph{}
La utilització de la solució de mapes de Google ve des del començament del desenvolupament del projecte, i de fet es pot considerar l'opció natural si es volen desenvolupar aplicacions que facin servir mapes en Android, ja que està molt ben integrada, és força versàtil i molt ben documentada.

\paragraph{}
Tot seguit esmentaré en termes generals el procediment que segueix ZamiaDroid per utilitzar l'API de mapes de Google, que, de fet, és el procediment genèric que s'empra en la gran majoria d'aplicacions Android que en fan ús. 

En primer lloc cal obtenir una ``clau de desenvolupament'' proporcionada per Google que et permeti fer servir l'API i afegir aquesta clau al manifest de l'aplicació Android.

Després es pot crear una classe Java que hereti de MapView (que al seu temps hereta d'Activity).

Mitjançant aquest procediment es poden modificar les característiques del mapa a mostrar, i de fet aquesta és la metodologia més estesa quan es treballa amb APIS de Google, heretar de les classes de l'API i estendre-les segons les necessitats concretes del programador. Així si es vol afegir una capa d'informació sobre aquest mapa s'hereta de la classe Overlay, per exemple, i aquest Overlay propi s'afegeix al MapView, etc.

Un cop fet això, normalment només cal tractar de manera adient aquesta classe i integrar-la amb la resta d'activities de l'aplicació.

\paragraph{}
Actualment (des de febrer de 2013) ha aparegut una nova versió de l'API que han anomenat v2, que permet (entre d'altres coses) visualitzar mapes tridimensionals, i fa servir un procediment lleugerament diferent al esmentat anteriorment. Però quan es va realitzar l'estudi encara no estava disponible, i Zamia no la utilitza (no es preveu la seva utilització a curt termini) així que no la comentarem a l'estudi.

\paragraph{}
ZamiaDroid també fa ús d'una biblioteca externa anomenada MyTracks que proporciona un servei per guardar i mostrar les rutes recorregudes pels dispositius mòbils, que fa servir el gps i interactua amb GoogleMaps.

\paragraph{}
Zamia a més permet exportar les dades recollides d'un projecte en els següents formats:

\begin{itemize} 
                \item{KML:} Un esquema d'XML que representa un format genèric i estàndard per representar dades sobre mapes del que ja s'ha parlat \hyperlink{estudi-kml}{aquí}.
                \item{JSON:} Acrònim de JavaScript Object Notation) és un format popular per la transmissió de dades. El projecte final de carrera original ja feta servir JSON com a format de comunicació entre el que era el servidor de mostres i el programa client del dispositiu mòbil, es tracta d'un format lleuger i còmode i al hora versàtil i és un estàndard molt estès.
                \item{Fagus:} Es tracta d'un format propi, una variant  d'XML preparat per a ser usat en un programa de gestió de plantes creat pel departament de la Facultat de Biología, que també desenvolupa el Zamia. (\url{http://biodiver.bio.ub.es/veganaweb/main/?section=../fagus/content.jsp}).
                \item{TAB:} Un fitxer de text pla amb les dades separades per tabulacions que permet treballar fàcilment amb programes de full de càlcul.
                \item{Zamia:} Es un fitxer XML amb un format propi pensat per a ser utilitzat en el mateix dispositiu mòbil com a còpies de seguretat, o com format de comunicació entre instàncies del programa en altres dispositius.
\end{itemize}

\paragraph{}
Zamia presenta moltes d'altres funcionalitats més o menys específiques per a les tasques de recol·lecció de dades i/o per la ajuda en aquesta obtenció, com ara la comunicació amb un servidor per obtenir llistes taxonòmiques (Thesarus) que facilitin la introducció de dades, o consultes a bases de dades remotes, però a grans trets aquestes serien les seves funcionalitats.

\paragraph{}
Com es pot veure, en una aplicació tant encarada al treball de camp, la possibilitat de treballar amb mapes offline resultaria molt pràctica, per a poder recol·lectar dades i/o visualitzar-les sobre el terreny fins i tot quan no es disposa d'una bona connexió de xarxa o no n'hi ha cap de disponible.

A més la filosofia de codi obert del projecte lliga molt bé amb la utilització d'OpenStreetMap, i poder fer-lo servir també beneficiaria al projecte.

\paragraph{}
En resum, tot i que ZamiaDroid és una aplicació pràctica que s'està fent servir actualment de manera satisfactòria, també una aplicació en constant desenvolupament que es podria beneficiar d'algunes millores no prioritàries pel seu equip de desenvolupadors però si bones de tenir.

%Interesting Apps
\subsection{OsmAnd}

OsmAnd (OSM Automated Navigation Directions) és una aplicació de navegació basada en OpenStreetMap.

Com a característiques més interessants destaco:
\begin{itemize}

\item 
Mostrar mapes vectorials d'OSM (*.osm.pbf, *.obf) i altres tipus de mapes basats en cel·les (Mapnik, Osmarender, Google Maps/Satellite/Terrain, CloudMade, Cyclemap, OpenPisteMap, MapSurfer.Net, Microsoft Maps/Earth/Hybrid)

\item 
És capaç de mostrar mapes offline.

\item
Permet afegir POIs (punts d'interès) a OpenStreetMap.

\end{itemize}

\paragraph{}
El primer que l'aplicació et comenta al iniciar-la per primer cop és que cal que et descarreguis mapes de les zones que necessites, i que la versió gratuïta te un limit de 10 mapes.

\paragraph{}
Els mapes de zones tenen una mida considerable, de l'ordre de 30Mb per una zona dels voltants d'una ciutat gran, i fins a 400Mb per un país sencer com Anglaterra o Espanya.

\paragraph{}
Les funcionalitats de l'aplicació estan pensades per ajudar en la navegació de mapes, sobretot per la conducció amb automòbil, tot i que també te modes per a vianants i ciclistes.

\paragraph{}
A més de veure i navegar els mapes OsmAnd pot ser usat per millorar la qualitat de les dades de OpenStreetMap. Des de la mateixa pantalla de navegació es dona accés fàcil per poder crear i publicar nous punts d'interès (POI) o corregir errors de les dades d'OSM.

Per aconseguir això cal configurar OsmAnd perquè faci servir la teva informació de registre d'OSM des de les preferències, i un cop realitzat això es poden crear nous POIs des d'un menú contextual sobre el mapa.

De manera semblant es poden proposar correccions d'errors de les dades OSM.

Aquesta funcionalitat resulta interessant perquè facilita l'aport comunitari i la voldria destacar especialment.

\paragraph{}
Malgrat això l'enfoc d'aquesta aplicació és força diferent a les necessitats del projecte, ja que dona molta prioritat a les capacitats de navegació de mapes mitjançant GPS i la seva capacitat per suportar mapes fora de línia, tot i que és molt marcada, no sembla donar facilitats per a la utilització de mapes gestionats per l'usuari de manera local, sinó més aviat pretén que es facin servir mapes proporcionats pels serveis de l'aplicació. 

\paragraph{}
Tot i així és possible treballar amb mapes offline gestionats pels usuaris. El mecanisme que es proporciona per generar mapes d'OsmAnd és processar dades en format OSM amb una aplicació d'escriptori externa (OsmAndMapCreator) i transferir el fitxer resultant en format *.obf al dispositiu que es desitgi.

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/osmand01.eps}
        \caption{Pantalla principal d'OsmAnd.}\label{fig-osmand01}
\end{figure}

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/osmand00.eps}
        \caption{Captura d'OsmAnd.}\label{fig-osmand00}
\end{figure}

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/osmand04.eps}
        \caption{Captura del gestor de mapes offline d'OsmAnd.}\label{fig-osmand04}
\end{figure}

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/osmand05.eps}
        \caption{Captura de descarrega de mapes offline d'OsmAnd.}\label{fig-osmand05}
\end{figure}

\FloatBarrier
\subsection{OruxMaps}

OruxMaps és un cas una mica especial, ja que no és software lliure, tot i que si software ``gratuït'', però l'afegeixo a l'estudi ja que em va interessar perquè utilitza la biblioteca (que si que és software lliure) mapsforge, que més endavant explicaré amb més deteniment, i em va anar bé analitzar l'aplicació a nivell funcional per comprendre les capacitats d'aquesta i com han estat aprofitades per a desenvolupar aplicacions de GIS.

\paragraph{}
Oruxmaps permet treballar en dos modes, el mode online, que permet veure diversos tipus de mapes (GoogleMaps, OpenStreetMap, Microsoft Maps, etc.), i el mode offline amb mapes generats especialment per a l'aplicació des d'una eina d'escriptori.

\paragraph{}
També permet enregistrar camins fent servir el GPS, i exportar aquests camins en format gpx i kml.

\paragraph{}
A més inclou funcions de navegació per veu, de càlcul d'estadístiques sobre els recorreguts realitzats, alarmes de proximitat, suport pel ``geocaching'', monitorització de freqüència cardíaca fent servir dispositius bluetooth externs, etc.

\paragraph{}
El funcionament de l'aplicació és una mica confús, ja que te moltes funcionalitats i la pantalla es veu una mica plena d'opcions, i això fa que a nivell d'interfície costi una mica adaptar-se a l'aplicació.

\paragraph{}
A part d'això Oruxmaps resulta un programa molt complert i extens, que mostra la capacitat de la biblioteca mapsforge per a mostrar mapes de diverses fonts (entre elles de OpenStreetMap) i les seves capacitats offline.  

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/oruxmaps01.eps}
        \caption{Captura de la pantalla principal d'oruxmaps.}\label{fig-oruxmaps01}
\end{figure}

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/oruxmaps02.eps}
        \caption{Captura dels menus d'oruxmaps.}\label{fig-oruxmaps02}
\end{figure}

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/oruxmaps04.eps}
        \caption{Captura de selecció de fitxers d'oruxmaps.}\label{fig-oruxmaps04}
\end{figure}

\FloatBarrier
\subsection{gvSIG Mini}

gvSIG és un projecte que va néixer l'any 2004 a València per tal de migrar els sistemes de la Conselleria d'Infraestructures i Transports (de València) a sistemes de software lliure. Això significa que a priori tenien uns objectius i una manera de fer molt lloables, i també recursos per portar a terme aquests objectius. Però al mateix temps aquests objectius pretenien solucionar problemes força concrets i específics, molt enfocats a les necessitats del ministeri.

\paragraph{}
El projecte gvSIG ha anat desenvolupant diferents productes, per a diferents escenaris i entorns.

\paragraph{}
La versió de gvSIG pensada per funcionar en dispositius Android s'anomena gvSIG Mini per Android (o gvSIG per abreujar). Això significa que es tracta d'un port de la versió de gvSIG per a dispositius mòbils (gvSIG Mobil) a Android.

\paragraph{}
gvSIG mini per Android és una aplicació de mapes molt complerta i permet visualitzar mapes de ``tiles'' (o tessel·les) provinents de fonts molt diverses, per exemple pot descarregar-se les tessel·les generades a partir de OpenStreetMap o el que proporciona GoogleMaps, o Bing (de Microsoft) o els de YahooMaps per anomenar-ne uns quants. 

I també dona la possibilitat de guardar aquestes tessel·les descarregades a la memòria del dispositiu i disposar-ne encara que no es tingui connexió a la xarxa (offline). El problema amb això és que es un mètode que descarrega una gran quantitat d'imatges i a vegades (depenent de quants nivells de zoom i de quina àrea es demani descarregar) pot exhaurir l'espai del dispositiu o col·lapsar els servidors (sobretot els de OpenStreetMap i d'alguns altres serveis de mapes, que tenen límits força restrictius per evitar descàrregues de tessel·les en massa).

Permet a més carregar capes addicionals sobre els mapes des de servidors externs que compleixin els estàndards de WMS (Web Map Service), TMS (Tile Map Service) o des de fitxers de capes en format text pla.

Permet cercar adreces i direccions.

També permet utilitzar-lo com a navegador d'adreces (similar al navegador d'un automòbil), tot i que aquesta funcionalitat no funcionava del tot bé en el dispositiu on vaig provar l'aplicació.

\begin{figure}[ht]
\begin{minipage}[b]{0.45\linewidth}
  \centering
        \includegraphics[height=0.3\textheight]{misc/gvSIG_01.eps}
  \caption{Menú principal de gvSIG.}\label{fig-gvsig1}
\end{minipage}
\hspace{0.5cm}
\begin{minipage}[b]{0.45\linewidth}
  \centering
        \includegraphics[height=0.3\textheight]{misc/gvSIG_02.eps}
  \caption{Pantalla principal de gvSIG.}\label{fig-gvsig2}
\end{minipage}
\end{figure}

\begin{figure}[ht]
\begin{minipage}[b]{0.45\linewidth}
  \centering
        \includegraphics[height=0.3\textheight]{misc/gvSIG_03.eps}
  \caption{Menú de descàrrega de tessel·les de gvSIG.}\label{fig-gvsig3}
\end{minipage}
\hspace{0.5cm}
\begin{minipage}[b]{0.45\linewidth}
  \centering
        \includegraphics[height=0.3\textheight]{misc/gvSIG_04.eps}
  \caption{Pantalla de configuració de gvSIG.}\label{fig-gvsig4}
\end{minipage}
\end{figure}

\begin{figure}[ht]
  \centering
        \includegraphics[height=0.3\textheight]{misc/gvSIG_05.eps}
  \caption{Pantalla de configuració de servidors de mapes.}\label{fig-gvsig5}
\end{figure}

\FloatBarrier
\subsection{Quantum GIS for Android}

\hypertarget{estudi-qgis}{}Quantum GIS (QGIS) és un Sistema d'informació Geogràfica complet i molt potent, de codi obert (GNU Public License) i multi-plataforma (corre en Linux, Unix, Mac OSX, i fins i tot Windows). Permet treballar amb la majoria de formats vectorials, ``raster'' i formats de bases de dades.

\paragraph{}

El QGIS proporciona diferents aplicacions que poden ser usades segons convingui:

\begin{itemize}
\item{QGIS Desktop}  Una aplicació d'escriptori que ofereix funcionalitats usuals en sistemes GIS per a visualitzar, editar i analitzar informació geogràfica.
\item{QGIS Browser} Una aplicació centrada a visualitzar simples i ràpidament dades locals o online (WMS).
\item{QGIS Server} Uns servidor que respecta L'estàndard WMS 1.3 que pot ser configurat fàcilment fent servir projectes realitzats amb l'aplicació QGIS Desktop.
\item{QGIS Client} Una ``façana'' (front-end) basada en OpenLayers i GeoExt, destinada a resoldre les necessitats de proveir mapes basats en la web.
\end{itemize}

\paragraph{}

Quantum GIS, però, no estava encarat a dispositius mòbils.

Això va canviar en ocasió de l'esdeveniment Google Summer code de 2011, quan es va crear una adaptació anomenada ``QGIS mobile'' pensada per funcionar en sistemes Android.

Inicialment estava plantejat com una conversió 1-a-1 de l'aplicació QGIS d'escriptori que tenia com a objectiu les plataformes Android amb pantalles més grans (tauletes d'unes 10.1'').

Més endavant s'ha estat transformant en una aplicació també pensada per telèfons, amb una interfície d'usuari més minimalista. Però el desenvolupament d'aquesta versió encara està en execució.

\paragraph{}

Aquest és un ``port'' molt interessant pel projecte actual, ja que ha estat clau i molt interessant per comprendre i avaluar la complexitat de portabilitat d'un projecte en c++ i que utilitza les biblioteques gràfiques Qt a un entorn tan peculiar com Android. 

En aquest cas concret, fent us de la ``traducció'' de les biblioteques Qt a Android, anomenades Necessitas, i més concretament de l'aplicació Ministro II, que les descarrega, el QGIS mobile es capaç de mostrar mapes amb una interfície basada en Qt (no del tot igual a la de l'aplicació d'escriptori naturalment, però si basada en ella).

\paragraph{}

Ara bé, després d'informar-me de la solució que plantejaven, i de l'excitament inicial, van sorgir complicacions a l'intentar avaluar l'aplicació proporcionada.

\paragraph{}
El sistema d'instal·lació de totes les biblioteques necessàries per l'execució de QGIS for Android és força complex i llarg. Els desenvolupadors del projecte proporcionen eines per facilitar-lo, però el fet que depengui de tants factors pot ser un dels elements que en compliquen la detecció de problemes. En primer lloc cal instal·lar tot el suport de les biblioteques de Qt a Android, per això l'aplicació Ministro II és de molta utilitat, i es un Procés que vaig aconseguir finalitzar aparentment sense cap error perceptible.

\paragraph{}
Posteriorment cal instal·lar una de les versions de l'aplicació pròpiament dita, que amb la ajuda d'un programa instal·lador ens permeten seleccionar.

\paragraph{}
A part de les diferents versions més o menys estables (o com a mínim provades fins a cert punt) i les versions més recents possiblement inestables. També existeixen alguns empaquetaments específics que contenen optimitzacions (armeabi v7a) que només poden ser aprofitades per a alguns dels models més nous de dispositius.

\paragraph{}
Arribats en aquest punt es van provar extensivament la majoria de les versions disponibles en aquell moment, i es van obtenir resultats similars per a totes elles (errors greus que impedien el carregament de l'aplicació). 

\paragraph{}
Després de comprovar que sorgien problemes similars en executar el programa en tots els dispositiu de proves físics de que \hyperlink{plan-hardware}{disposava} en aquell moment (HTC Magic, Google Nexus One i un Samsung Galaxy Tab 7), i veient com també resultava impossible executar-lo degudament en cap de les instàncies del emulador d'Android.

Es va concloure que existien greus problemes d'incompatibilitat relacionats amb els dispositius que teníem a l'abast.

\paragraph{}

A continuació mostro una taula amb els dispositius que segons la web oficial del projecte QGIS for Android, a dia d'avui permeten la seva utilització sense cap mena de problemes:

$$
\begin{tabular}{ | l | c | c | }
  \hline 
  Device & Android version & Status \\
  \hline 
  ASUS Transformer & 3.2 & OK	\\
  \hline 
ASUS Transformer TF300 &	4.0 & 	OK	\\
  \hline 
Lenovo ThinkPad 6 Tablet &	3.1 &	 OK \\	
  \hline 
\end{tabular}
$$

Com es pot veure es tracta d'un segment de dispositius encara força limitat i de gamma més aviat alta.

\paragraph{}

Tal i com ho vam interpretar, aquest fet posa en evidència les dificultats inherents del plantejament de ``portar'' aplicacions d'escriptori complexes a la plataforma Android, i va ser un dels motius per acabar realitzant el projecte tal i com esta plantejat.

\paragraph{}

Com a apunt final cal dir, però, que QGIS for Android és una opció molt atractiva i encara en constant desenvolupament, a la qual és interessant seguir la pista, ja que en un futur no gaire llunyà podria resultar una eina molt potent en el camp d'estudi que tractem.


\subsection{pyroute}

Pyroute es un programa escrit en Python que semblava molt interessant per les similituds amb el plantejament del projecte present.

Es tracta d'una versió gràfica per a dispositius mòbils d'una interfície de línia de comandes pensada per calcular rutes sobre mapes de osm.

\paragraph{}

Tal i com s'especifica a la pagina de Pyroute de la wiki de open street maps, esta pensat per córrer sobre Linux, windows i OpenMoko, que es un sistema operatiu lliure per a dispositius mòbils, però no àmpliament suportat.

\paragraph{}

Utilitza Python, naturalment, però també cairo i Gtk per a mostrar les interfícies i els gràfics (a traves de pycairo i pyGtk).

\paragraph{}

Per desgràcia les biblioteques de cairo i pyGTk no sembla que estiguin disponibles actualment a la plataforma Android, així que intentar portar aquest projecte a Android va veure's poc viable.

\paragraph{}

A més existeix la possibilitat que el projecte pugui estar abandonat, ja que a la pagina es menciona que s'està reemplaçant per un altre projecte anomenat ``rana'' que tampoc sembla molt actiu.

\subsection{gmapcatcher}

Interessant per la seva capacitat offline molt marcada i per haver estat desenvolupat en Python, comprendre els mecanismes que utilitza per a suportar mapes offline sempre és una aportació interessant al projecte, i a més, un possible port a Android hauria estat molt interessant.

\paragraph{}
El gmapcatcher és una aplicació d'escriptori capaç de descarregar-se de diverses fonts d'internet cel·les de mapes (tiles) i guardar-los per a ser usats offline.

\paragraph{}
Alguns dels proveïdors de mapes dels quals es pot descarregar la informació són OpenStreetMap, CloudMade, Yahoo, OpenCycleMap o Seznam. Anteriorment es podia descarregar també de Google maps, però degut a una queixa de Google respecte a l'incompliment dels seus termes d'us ara ja no es permet\cite{bib-gmapcatcher-issue}.

\paragraph{}
Naturalment, a banda de descarregar-se aquesta informació de la xarxa, el programa també pot gestionar aquest mapes, carregar-los de fonts locals, i proporciona una interfície per permetre a l'usuari seleccionar quines parts d'aquests mapes es volen guardar.

A continuació segueix una petita avaluació funcional del programa. Per a informació més detallada podeu consultar la seva guia d'utilització\cite{bib-gmapcatcher-userguide}:

\paragraph{}

La interfície principal del programa consta d'un mapa envoltat de barres d'eines (\autoref{fig-gmapcatcher-main}).

\begin{figure}[ht]
  \centering
        \includegraphics[width=0.8\textwidth]{misc/gmapcatcher_main_window.eps}
  \caption{Interfície principal de gmapcatcher.}\label{fig-gmapcatcher-main}
\end{figure}

\paragraph{}
A traves de les barres d'eines es pot controlar el nivell de zoom del mapa, cercar llocs, especificar el mode de treball (online/offline), accedir al menú de configuracions, etc.

\paragraph{}
La funcionalitat més destacada i que resultava més interessant és la de descarrega de mapes.

\paragraph{}
Per descarregar una zona del mapa cal clickar amb el ratolí sobre el mapa i seleccionar l'opció ``batch download'' del menú contextual desplegable que apareix (\autoref{fig-gmapcatcher-rclick}). Això es podria traslladar a Android com a una pressió sobre el mapa durant un temps prolongat.

\begin{figure}[ht]
  \centering
        \includegraphics[height=0.3\textheight]{misc/gmapcatcher_gmap_rclick.eps}
  \caption{Menú desplegable contextual.}\label{fig-gmapcatcher-rclick}
\end{figure}

\paragraph{}
Un cop triada aquesta opció apareix un menú que et permet centrar la posició del mapa i definir-ne l'àrea a descarregar, així com el nivell mínim i màxim de zoom que es guardarà (\autoref{fig-gmapcatcher-download}): 

\begin{figure}[ht]
  \centering
        \includegraphics[width=0.8\textwidth]{misc/gmapcatcher_download_window.eps}
  \caption{Menú de descàrrega.}\label{fig-gmapcatcher-download}
\end{figure}

\paragraph{}
Així l'us normal del programa seria obrir-lo en mode online, descarregar les parts de mapa que es desitgen als nivell que es vulguin després estarien disponibles permanentment.

\paragraph{}
La mida dels mapes, però, continua sent molt gran, sobretot si es tenen nivell de zoom molt detallat. Aquest és un ``defecte'' que tenen tots els sistemes que he vist d'emmagatzemar mapes de tessel·les.

\paragraph{}
A part d'aquesta funcionalitat, però, l'aplicació no proporcionava gaires més opcions. Així que per desgràcia les capacitats del projecte eren més limitades del que necessitàvem. 

Per exemple, mancaven les opcions de carregar mapes en kml i gml, un dels objectius del projecte. Cosa que es podia haver afegit a gmapcatcher. 

Però també es va considerar que els mètodes d'interacció amb l'usuari que proporcionava gmapcatcher eren massa complexos i fragosos, molt dependents dels mètodes d'entrada tradicionals (teclat i ratolí) i amb uns dissenys de menús bastant ``petits'', i per tant molt difícilment portables a dispositius com els telèfons mòbils.

\paragraph{}

Si a més valorem que actualment no es permetia dibuixar línies i polígons als mapes mostrats, i la informació dels marcadors de posició que sí que permetia afegir era molt limitada, i que per tant això era una altre aspecte que també s'hauria de modificar, i que totes aquestes característiques es desviaven de l'objectiu inicial del projecte gmapcatcher. 

A més cal afegir la dificultat de portar a Android projectes com aquest, degut a la manca de suport per a les biblioteques Gtk i a la complexitat de portar amb èxit projectes de Python a Android.

\paragraph{}

Per totes aquestes raons es va decidir simplement estudiar a nivell de funcionalitats i comportament aquest projecte, i no d'implementació.

\paragraph{}
Tot i així és important mencionar-lo per considerar-ne els mètodes que utilitza de gestió de mapes offline i també per aclarir alguns dubtes que existien respecte les polítiques i els termes d'us d'alguns proveïdors de mapes (concretament Google) en referència a la descarrega en massa de informació.

\FloatBarrier
\subsection{Taula resum d'aplicacions}

A continuació es pot veure una taula/resum de les aplicacions considerades i si tenen o no les capacitats marcades com a objectius del projecte: Android (and), Mapes sense connexió a la xarxa (offline), carregar mapes s'OpenStreetMap (osm), carregar fitxers KML (kml), carregar fitxers GML (gml), dibuix de polígons i altres formes geomètriques (poly), realitzar càlculs sobre mapes (calc) i ser software lliure (open). \\

\begin{center}
\begin{tabular}{ | l | c | c | c | c | c | c | c | c | c | }
  \hline 
  \textbf{Aplicació} & and & offline & osm & kml & gml & poly & calc & open \\
  \hline 
  ZamiaDroid & \cmark & \xmark &  \xmark & \xmark & \xmark & \xmark & \xmark & \cmark \\
  OsmAnd & \cmark & \cmark &  \cmark & \xmark & \xmark & \xmark & \xmark & \cmark \\
  OruxMaps & \cmark & \cmark &  \cmark & \cmark & \xmark & \xmark & \xmark & \xmark \\
  gvSIG Mini & \cmark & \cmark &  \cmark & \xmark & \xmark & \xmark & \xmark & \cmark \\
  QGIS & \textasciitilde{} & \cmark &  \cmark & \cmark & \cmark & \cmark & \cmark & \cmark \\
  pyroute & \xmark & \xmark &  \cmark & \xmark & \xmark & \xmark & \xmark & \cmark \\
  gmapcatcher & \xmark & \cmark &  \cmark & \xmark & \xmark & \xmark & \xmark & \cmark \\
  \hline 
\end{tabular} \\
\tiny{\textasciitilde{} = suport parcial \cmark = suportat \xmark = no suportat} 
\end{center}

%Interesting Engines
\section{Motors de render i biblioteques analitzades}

Després d'analitzar aplicacions, es van cercar biblioteques que poguessin ajudar a complir els requisits del PFC. Algunes de les biblioteques són les mateixes que fan servir les aplicacions analitzades. 

\par
En aquest cas no tan sols s'ha valorat les biblioteques a nivell funcional, ja que a més de cercar biblioteques que ja complissin els objectius del projecte, també es posava atenció a valorar-les com a possible base per la biblioteca d'aquest PFC, és a dir, també s'ha valorat com podrien ser esteses per afegir-hi les funcionalitats que hi mancaven.

Tal com succeïa a l'estudi d'aplicacions, no s'han valorat exclusivament biblioteques implementades en Android. També s'han valorat biblioteques dissenyades per altres plataformes, i la possibilitat que eventualment poguessin ser ``portades''.

\subsection{osmdroid}

\hypertarget{estudi-osmdroid}{}osmdroid és un projecte de biblioteca per a proporcionar eines i mètodes de visualització de dades de OpenStreetMap per a la plataforma Android. 

Entre d'altres coses vol proporcionar una biblioteca de mapes alternativa i lliure a la de Google, però amb una API similar.

\paragraph{}

osmdroid va ser creat per Nicolas Gramlich, que encara n'és propietari de projecte. El creador de osmdroid va abandonar parcialment el projecte i va dedicar els seus esforços a AndNav, que era un projecte de implementació de navegació gps basat en osmdroid, però que sembla a ser que no ha estat actualitzat des de 2010.

\paragraph{}

Deixant de banda això osmdroid sembla que encara està mantingut per una comunitat de desenvolupadors.

I segons la seva web\cite{bib-osmdroid} ha estat utilitzat en bastants projectes, ja sigui utilitzant la biblioteca que proporcionen íntegrament o bé fent un fork del seu codi font i modificant-la. Alguns d'aquests projectes són OsmAnd, AndNav2, OpenGPX, etc. Aquesta confiança dels desenvolupadors, en certa manera els avala.

\paragraph{}

Un fet negatiu a destacar és que les biblioteques osmdroid no proporcionen un clar suport per treballar fora de línia. De fet, als fòrums de desenvolupament d'osmdroid, existeixen discussions per afegir-hi aquesta capacitat, però encara no hi ha una solució definitiva.

I el fet d'estar totalment centrat en mostrar mapes osm implicava que, de fer servir aquesta biblioteca pel projecte caldria implementar la part de kml i gml a part.

\paragraph{}

Malgrat això aquesta era una opció que es va tenir molt en compte a l'hora d'escollir una biblioteca en la que basar-se per implementar el projecte, i de no haver trobat solucions més adients hauria estat la escollida.

\subsection{osmarender}

Osmarender és un motor de renderitzat basat en regles per a generar imatges SVG a partir de dades OSM.

\paragraph{}

Pren com a dades d'entrada un fitxer de regles i un conjunt de dades d'OpenStreetMap, i genera un fitxer gràfic de dades vectorials en format SVG que concorda amb l'estil definit al fitxer de regles.

\paragraph{}

Aquest motor de renderitzat semblava força limitat a generar imatges ``estàtiques'' i mancava de suport per a mètodes d'entrada i per a interaccionar amb els mapes generats i editar-los de manera gràfica (afegir punts d'interès, etc).

\paragraph{}

Aquesta simplicitat, i la independència d'una plataforma concreta que aporta treballar amb SVG, el feia (a priori) més senzill de portar a Android que d'altres alternatives. 

Però aquest mateix plantejament ``simplista'' del projecte implicava haver de fer moltes modificacions per poder-hi implementar tots els objectius que requeríem. 

Malauradament, a més, el projecte no esta essent mantingut des del març de 2012 cosa que feia témer que ens mancaria suport per a qualsevol problema que poguéssim tenir. Per això es va preferir estudiar més a fons altres alternatives.

\subsection{OpenLayers}

OpenLayers és un famós software que permet mostrar un mapa dinàmic a qualsevol pàgina web. És completament gratuït i de codi obert (llicència FreeBSD) i esta programat en JavaScript.

\paragraph{}

La portabilitat de la tecnologia web va fer plantejar-nos-en la utilització per a mostrar els mapes a Android.

\paragraph{}

Dintre de la comunitat de software lliure OpenLayers és una de les solucions més utilitzades per afegir mapes interactius a les webs. 

\paragraph{}

D'haver optat per a la utilització de tecnologia web, aquesta opció s'hagués estudiat amb més deteniment. Però els dubtes que van sorgir pel que fa a la integració d'aquesta tecnologia en dispositius Android (amb navegadors web específics), així com la manca de funcionalitats encarades al treball fora de línia, i l'existència de solucions més atractives va fer que s'optés per abandonar aquesta idea. 

\subsection{HTML5 Geolocation}

Aquesta és una opció realment interessant i qui sap si podríem estar parlant de la solució més portable i pràctica per a la geo-localització i els sistemes GIS mòbils en general en un futur molt pròxim.

\paragraph{}

En aquest apartat em refereixo a les capacitats que te HTML5 per a permetre desenvolupar sistemes GIS i no tan sols a la geo-localització en concret.

Estem parlant d'acceleració gràfica per hardware, millor capacitat offline i de cache i accés als dispositius. Combinant totes aquestes possibilitats tenim unes condicions ideals per desenvolupar sistemes GIS que a priori haurien de ser el màxim de portables possibles, ja que qualsevol navegador que suportes HTML5 les podria fer funcionar.

\paragraph{}

Així tot sembla indicar que només falta un petit pas perque es puguin realitzar aquest tipus de programes. Que es que HTML5 esdevingui un estàndard real i la majoria dels navegadors el suportin.

\paragraph{}

Per desgràcia sembla a ser que aquest horitzó no resulta del tot pròxim encara, i al dependre en gran mesura del desenvolupament de navegadors web compatibles estem limitats en el que podem fer per arribar-hi.

\paragraph{}

Per tant ara per ara parlar d'implementar una solució utilitzant aquesta tecnologia  es tracta gairebé d'una pura especulació, ja que l'estàndard HTML5 a dia d'avui encara no esta ni completament implementat ni acceptat, en el moment de redacció d'aquesta memòria es troba en estat de ``working draft''.

\paragraph{}

Per si no fos poc, aquest tipus de solució planteja alguns dubtes, com ara si els dispositius actuals (o amb uns pocs anys d'antiguitat) serien capaços de fer funcionar navegadors que consumeixin tants recursos com sembla a ser que cada vegada tendeixen a fer, i que serien requerits per poder executar codi HTML5 amb garanties.

De ser així utilitzar HTML5 potser suposaria impossibilitar a un gran nombre de gent la utilització dels sistemes desenvolupats, i això és un factor que s'ha de considerar. 

O fins i tot qüestions de seguretat que poden sorgir al donar tanta capacitat als navegadors web.

\paragraph{}

I al tractar-se d'un sistema tan íntimament relacionat amb Internet, naturalment sorgeix la pregunta de si, malgrat les millores en el sistemes de cache que proclamen els desenvolupadors de HTML5, les capacitats fora de línia d'aquesta mena de solucions serien tant limitades com aparenten, o realment seria viable que algú sense connexió pogués treballar amb normalitat.

Suposo que es necessita una mica més de temps i de proves amb HTML5 per poder respondre a aquestes preguntes i saber si realment pot ser una bona solució per implementar sistemes GIS.

\paragraph{}

Però malgrat això és interessant observar cap a on sembla que poden anar els trets en un futur pròxim, i jugar amb els exemples de demostració que actualment existeixen\cite{bib-html5-demos}.

\subsection{mapnik}

Mapnik és un conjunt d'eines per renderitzar mapes. Entre moltes d'altres llocs es usada per generar el mapa de la web principal d'OpenStreetMap. 

\paragraph{}

Permet treballar amb una gran varietat de dades geoespacials i proporciona opcions d'estil molt flexibles per poder generar mapes per àmbits molt diversos.
Mapnik esta escrit en C++, però inclou també ``bindings'' per a treballar amb Python a un més alt nivell. Pot llegir ESRI shapefiles, PostGIS, TIFF, fitxers .osm, i qualsevol dels formats suportats per GDAL o OGR. 

Es distribueix per a la majoria de distribucions Linux i també està disponible per Mac OS X i per Windows, però pel que he pogut trobar No existeix una implementació de Mapnik per a Android tot i que es pot fer servir per generar externament mapes que es poden visualitzar al telefon.

\paragraph{}
Realitzar el procés de renderitzat de mapes en un dispositiu mòbil no és l'objectiu del projecte mapnik, i, de fet, tal i com esta plantejada la biblioteca resultaria força complicat a priori\cite{bib-mapnik-on-android}.

Però la gran popularitat de mapnik per a realitzar mapes en servidors, va fer que estudiéssim la possibilitat o existència de ports de mapnik a Android, sense èxit, per desgràcia.

\paragraph{}
Moltes de les aplicacions que s'han comentat anteriorment el fan servir o el suporten. Per exemple:

\begin{itemize}
        \item OsmAnd

        \item OruxMaps

        \item gvSIG Mini
\end{itemize}

\subsection{mapsforge}

Mapsforge és un atractiu projecte que promet proporcionar biblioteques de codi obert i lliure per a aplicacions basades en OpenStreetMap que permeten mostrar mapes en dispositius Android.

Segons la wiki d'OpenStreetMap mapsforge proporciona una biblioteca gratuïta i lliure que permet renderitzar mapes vectorials fora de línia (i de més tipus) per Android. Amb una API senzilla es pot construir una aplicació de mapes en menys de 30 línies de codi i suporta Overlays, amb punts d'interès (POIs) i formes poligonals.

\paragraph{}
El projecte va començar l'any 2008 a l'institut de ciències de la computació de la Freie Universität Berlin. I els seus principals objectius són proporcionar un conjunt d'eines lliures que permetin a la comunitat crear fàcilment aplicacions de mapes basades en OpenStreetMap. A tal efecte el projecte proporciona eines per renderitzar mapes, planificar rutes i ``navegació'', indexar i cercar punts d'interès (POIs), etc.

\paragraph{}
Algunes de les principals característiques que s'anuncien a la web mateix de mapsforge són:

\begin{itemize}

\item Us d'un format compacte per a la renderització ràpida de dades OpenStreetMap als dispositius.
\item MapView fàcil de fer servir molt similar a l'API de Google.
\item API de capes (overlay) flexible i potent.
\item Estils de mapes personalitzables mitjançant fitxers de configuració XML.
\item La biblioteca ocupa poc (300 KM aprox.).
\item Aplicació de demostració disponible per ajudar als desenvolupadors.
\item Proporciona eines per crear fitxers de mapes
\item 100\% lliure i de codi obert (llicència LGPL3)

\end{itemize}

\paragraph{}
En certs aspectes aquest és un projecte similar a \hyperlink{estudi-osmdroid}{osmdroid} però semblava tenir un millor suport per a mapes fora de línia i estar més activament desenvolupat, cosa que podia ser de gran ajuda.

\paragraph{}
Després de descarregar-me la biblioteca i provar l'aplicació de demostració, vaig concloure que, tot i que no aportava totes les funcionalitats que el present projecte necessitava, era un projecte interessant i a tenir molt en compte.

\section{Android}

A part de l'estudi tecnològic de motors de renderitzat de mapes i d'aplicacions similars, el projecte també requeria un estudi de la plataforma Android.

\paragraph{}
Sempre que es vol treballar sobre una plataforma aliena és necessari un cert estudi previ d'aquesta, per conèixer-ne les característiques i les particularitats a grosso modo, així com l'entorn de treball recomanat, les bones pràctiques a seguir i en resum la filosofia de treball.

Però en aquest cas concret l'estudi ha estat potser més extens del que seria habitual, ja que no tan sols es pretenia inicialment desenvolupar biblioteques i aplicacions en aquesta plataforma aliena, sinó que també es va plantejar la utilització de llenguatges de programació diferents de Java per fer-ho.

\paragraph{}
L'elecció d'un llenguatge de programació diferent a Java no sol ser habitual per desenvolupar en Android, ja que Java té un estatus de ``llenguatge preferent'' en aquesta plataforma, i s'espera que els desenvolupadors d'aplicacions el facin servir de manera exclusiva.

Això és degut, en part, al disseny del sistema operatiu Android, que malgrat estar basat en Linux aporta la majoria de les funcionalitats del sistema a través del Dalvik (la maquina virtual de Java especifica per Android). 

A continuació es pot veure un diagrama on es veu l'arquitectura d'Android i la importància del Dalvik (\autoref{fig-arquitectura-android}).

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/Android-System-Architecture.eps}
        \caption{Arquitectura del sistema Android.}\label{fig-arquitectura-android}
\end{figure}


Programar en Java no era un impediment del projecte, però tampoc una motivació, així que en un estadi inicial del projecte es va decidir estudiar la possibilitat de prescindir en la mesura del possible de Java i explorar altres alternatives de desenvolupament, en concret es volia mirar de treballar en Python, a ser possible.

\paragraph{}
Aquest estudi ha portat finalment a l'opció de crear una ``façana'' de SL4A per tal de poder oferir la capacitat de que scripts escrits en altres llenguatges de programació facin us de les biblioteques creades. 

Per això crec convenient dedicar aquesta secció del capítol d'estudi tecnològic a la recerca que es va realitzar sobre llenguatges alternatius pel desenvolupament en Android.

\paragraph{}
A continuació esmentaré les opcions estudiades a tal efecte, i també s'explicarà amb una mica més de detall tant la filosofia com la arquitectura de SL4A, que és l'opció que finalment s'ha escollit.

Així també apuntaré aquí els motius pel qual no s'ha desenvolupat el projecte íntegrament en Python, malgrat que aquest era l'objecte d'aquesta part de l'estudi.

\subsection{Estudi de llenguatges pel desenvolupament en Android}

Malgrat que Java és el llenguatge de programació preeminent pel desenvolupament d'Android, existeixen mètodes més o menys complexos per poder desenvolupar aplicacions en altres llenguatges de programació.

\paragraph{}

Alguns d'aquests mètodes són poc ortodoxos i/o estan encara en desenvolupament (s'ha de tenir en compte la relativa joventut de la plataforma) o han estat abandonats (encara que sigui relativament jove, hi ha hagut gran interès en ell i s'hi ha treballat amb gran promiscuïtat).

Així que l'estudi es va centrar valorar solucions provades i que requerissin poc nivell de modificació de la plataforma Android. 

Aquest criteri es va aplicar ja que no es volia condicionar des d'un bon principi que el resultat final del projecte només pogués ser executat en dispositius amb sistemes alterats.

\subsection{Native Developement Kit}

El Native Developement Kit (NDK) és un conjunt d'eines que permeten implementar aplicacions o ``parts'' d'aplicacions per a Android fent servir els llenguatges de programació ``natius'', o sigui C i C++. Són eines oficials d'Android desenvolupades per Google i ben documentades.

\par
Crear programes directament en C/C++ és oportú per a certs tipus d'aplicacions que pretenguin re-utilitzar codi de biblioteques o programes existents que ja estiguin implementades en aquests llenguatges.

O també podria ser útil en casos molt comptats per evitar algunes restriccions que dalvik (la maquina virtual de Java d'Android) imposa al codi que s'hi executa. Tot i que usualment (i tal i com s'adverteix a la documentació d'Android) utilitzar l'NDK no comporta un guany rellevant en el rendiment de les aplicacions.

\paragraph{}
En general no es recomana fer-lo servir si no és estrictament necessari, i s'adverteix als programadors que només l'emprin si la seva aplicació requereix algun dels beneficis que aporta, i mai, perquè el programador se senti més còmode programant en C/C++ que en Java.

\paragraph{}
Programar una aplicació ``autista'' per Android íntegrament en NDK no té moltes pegues, però el problema sembla a ser quan es vol comunicar el codi natiu amb el codi que s'està executant a la maquina virtual de Java. Aparentment aquest procés és més costós del que surt a compte. Així que normalment quan es programa amb NDK es perden les funcionalitats que proporciona l'API d'Android i/o s'afegeix un grau de complexitat elevat a les aplicacions.

\paragraph{}
Els exemples que es descriuen com a plausibles casos on l'NDK pot ser útil són majoritàriament programes auto-continguts (que no necessitin funcionalitats que proporcioni l'API d'Android), que necessitin realitzar càlculs intensius amb la CPU i que no necessitin molta memòria, com ara procés de senyals, simulació de física, etc.

\subsection{Compilació Creuada}

La compilació creuada no és altra cosa que generar codi per a una màquina que no te la mateixa arquitectura que la que estàs fent servir per compilar-lo. És a dir compilar des d'un sistema per a un altre.

En el cas que ens ocupa es tractaria de programar des d'un ordinador personal (amb arquitectura amd64 o i686, etc..) i compilar aquest codi fent servir un compilador ``especial'' i empaquetar-ho de manera que estigui tot preparat per executar-se a les màquines Android (normalment arm).

Aquest procés esdevé més complexe del que pot semblar a primer cop d'ull quan volem fer aplicacions que fan servir moltes biblioteques externes que no estan portades a Android (cal tenir en compte que algunes de les biblioteques que fa servir el sistema Android natiu no són les estàndards de C, sinó biblioteques lleugerament modificades, que dificulten un pèl les coses). 

\paragraph{}
Afortunadament existeixen algunes eines que serveixen per ajudar en aquesta tasca, que és més aviat incòmode. 

Aquestes eines han aparegut sobretot en alguns camps concrets, i com es pot veure a continuació, la majoria de les eines que he considerat, han estat pensades per adaptar algun entorn de desenvolupament de videojocs. 

Això es degut a que no existeixen eines per facilitat la compilació creuada d'aplicacions de GIS específicament, i al mateix temps les funcionalitats més difícils de portar a una plataforma com Android a priori semblen ser les gràfiques i les de gestió d'entrada (el que seria la interfície amb l'usuari final del sistema). 

Per això es va considerar que un ``framework'' pensat per fer funcionar videojocs podria suplir les necessitats gràfiques d'una aplicació de mapes. 

\subsubsection{Python for Android}

Si considerem la compilació creuada i l'objectiu concret de programar en Pyhton per a Android, el primer que es pot pensar és en cercar un mètode per compilar l'entorn de Python (intèrpret d'ordres, més biblioteques bàsiques). De manera que es pugui executar en un dispositiu Android.

\paragraph{}
A continuació resumeixo molt breument els passos a seguir per tal d'aconseguir-ho, extrets de la guia consultada\cite{bib-cross-compiling-python} per compilar Python per Android.

Aquest resum pot donar una idea més concreta del procés que cal seguir per aconseguir el que anteriorment s'ha esmentat (per a més detall consultar l'\hyperlink{annex-cross-compile-python}{annex}).

\paragraph{}
Una part important i complicada del procés ha estat facilitada en gran mesura amb un ``pedaç'' (patch) que molt amablement proporciona l'autor del tutorial, i basat en el que fa servir el projecte Py4A i amb algunes idees de la gent de Pygame For Android (que serà esmentat \hyperlink{estudi-pygame4and}{més endavant}), però en cas d'intentar portar un altre versió de Python o d'altres mòduls caldria desenvolupar-ne un altre. Aquest ``pedaç'' bàsicament prepara l'entorn d'execució Python per les condicions especials d'Android canviant alguns ``flags'' i la ubicació d'algunes biblioteques (tot i que no he entrat molt en detall a observar exactament quines).

Amb aquest pedaç podem modificar lleugerament el codi font de Python i configurar la seva compilació perquè pugui ser executat en l'entorn Android.

\paragraph{}
Després d'aplicar el ``pedaç'' cal modificar certes variables d'entorn i compilar Python fent servir el codi font modificat i un compilador per l'arquitectura ARM.

\paragraph{}
Naturalment aquest mètode presenta algunes complicacions pràctiques, més enllà de la complexitat del procés en si. En primer lloc, implica haver de sol·licitar que els usuaris facin un procediment semblant i preparin l'entorn per tal d'executar el codi que es crearà, o dissenyar i implementar un mecanisme que ho faci per ells.

\paragraph{}
En ambdós casos això pot resultar un impediment (o com a mínim una molèstia) per a molts potencials usuaris.

\paragraph{}
Tal i com s'ha plantejat el mètode a més, només es podrien crear i executar scripts que fessin ús de l'intèrpret de línia de comandes, ja que portar biblioteques d'interfícies gràfiques no és tant ``trivial''.

\paragraph{}
A més a més, el mecanisme presenta també el problema endèmic de la compilació creuada (que la resta de mètodes aquí considerats també presenten) que és la manca d'interacció amb les APIs d'Android, cosa que a priori limita molt la utilitat dels programes resultants i es volia evitar a ser possible.

\subsubsection{Pygame Subset for Android}

\hypertarget{estudi-pygame4and}{}Aquest cas concret és el port no tan sols de Python sinó també dels mòduls Pygame de Python. Pygame és, al mateix temps, un port de la SDL per a Python, i la SDL és la famosa biblioteca ``Simple DirectMedia Layer''. Una biblioteca disponible per a múltiples plataformes pel desenvolupament d'aplicacions gràfiques, molt estesa pel desenvolupament de jocs bidimensionals sobretot.

\paragraph{}
En el fons el nucli de funcionament de Pygame Subset for Android és molt similar a l'explicat en l'apartat anterior, però l'equip de Pygame Subset for Android ha desenvolupat una serie d'``scripts'' per ajudar en el procés, que resulten molt pràctics, i permeten fins i tot generar paquets estàndard d'Android APK. Així es pot distribuir l'aplicació programada sense necessitat que els usuaris hagin d'instal·lar prèviament l'entorn d'execució de Python al seu dispositiu, i és molt fàcil de desenvolupar i provar en el dispositiu.

\paragraph{}
Així el procediment per desenvolupar una aplicació mitjançant Pygame Subset for Android resulta tant senzill com fer el programa en Python sense preocupar-se de res, configurar-lo per al seu desplegament a Android invocant els scripts d'ajuda \emph{(android.py configure mygame)} contestar a una serie de preguntes de configuració i executar altre cop l'script per fer un paquet que podrà ser distribuït en un sistema Android \emph{(android.py build mygame release install)}.

Evidentment, prèviament a això cal instal·lar i configurar l'entorn de desenvolupament d'Android (SDK) i el de Pygame Subset for Android, però com es pot veure el procés de compilació creuada queda molt simplificat amb aquest mètode.

\paragraph{}
Tot i que, per exemple, he trobat alguns problemes per generar aplicacions que funcionin en tauletes noves (segurament degut a la versió d'arm que tenen configurat els scripts que generen el codi), en general sembla funcionar prou bé i permetre fer coses interessants.

\paragraph{}
El problema més gran de fer servir aquest sistema és, com en el cas anterior, a l'hora d'aprofitar alguna de les funcionalitats de l'API de Google. com ara accedir al GPS o a la llibreta d'adreces, per exemple.

A més no totes les funcionalitats de Python o de Pygame han estat portades (per això s'especifica ``subset'' en el nom) i tot i que les funcionalitats presents són suficients per a fer coses prou interessants, no hi havia garanties que no resultessin en problemes a l'intentar portar aplicacions GIS fetes amb Python, o aprofitar-ne parts.

\subsubsection{Necessitas}

També es va estudiar la possibilitat de crear les biblioteques fent servir les capacitats gràfiques que brindava el port de Qt a sistemes Android (tal i com fa \hyperlink{estudi-qgis}{QGIS} for Android).

Això hauria permès potser aprofitar alguna de les solucions GIS o de renderitzat de mapes implementades en sistemes d'escriptori que empressin Qt. Per això es va considerar Necessitas, que és el port de Qt per a Android.

\paragraph{}
Es tracta d'un projecte encara en fase de desenvolupament (al menys ho estava quan es va realitzar l'estudi) que té com a objectiu proporcionar una manera senzilla de desenvolupar aplicacions Qt per a la plataforma Android.

\paragraph{}
El projecte proporciona un SDK que inclou una modificació del QtCreator (un IDE per editar interfícies gràficament) i permet encarregar-se de tot ``màgicament'' (com molts IDE's).

\paragraph{}
En el fons el que fa aquest SDK és utilitzar l'NDK d'Android per compilar l'aplicació Qt generada com a biblioteca dinàmica i crear una aplicació Java ``wrapper'' que interactui amb l'entorn Android i faci d'interfície.

Teòricament això suposaria un petit ``overhead'' en l'execució d'aplicacions, però els creadors del projecte asseguren que és negligible.

\paragraph{}
A la banda del telèfon una aplicació distribuïda pel market  mateix (Ministro) s'encarrega de descarregar d'internet totes les biblioteques requerides degudament compilades i preparar així el sistema Android per la seva utilització.

\paragraph{}
Però tenint en compte les dificultats que la instal·lació i avaluació de \hyperlink{estudi-qgis}{QGIS} for Android va tenir, l'estadi de desenvolupament del projecte i l'existència d'altres solucions es va decidir no fer ús d'aquesta alternativa.

\subsubsection{Conclusió}

Generalitzant molt, podem dir que la compilació creuada aporta la versatilitat de poder desenvolupar per Android fent servir ``frameworks'' alternatius, a costa de perdre funcionalitats ``estàndards'' d'Android, i/o d'afegir un nou nivell de complexitat tant al procés de desenvolupament com als sistemes que es desenvolupen, cosa que pot comportar problemes de compatibilitat en alguns dispositius. 

\paragraph{}
A més en algunes de les solucions estudiades he notat una petita manca de ``rodatge''. Sense anar més lluny moltes de les solucions provades estaven en fase de desenvolupament al intentar provar-les, i algunes van resultar en problemes a l'hora de fer proves.

\paragraph{}
A tot això hi hem d'afegir que la idea que es tenia a l'inici del projecte de la integració amb ZamiaDroid (com s'explicarà més endavant) es complicava si es volia seguir aquest camí.

\paragraph{}
Per aquests motius, i perquè es va trobar una solució que semblava més encertada, es va decidir no emprar cap d'aquests mètodes, encara que alguns resultaven atractius o interessants, i també val a dir, una mica aterridors.

\paragraph{}
Potser en un futur no gaire llunyà algun d'aquests entorns esdevindrà una solució estable i més afable que pugui portar (esperem) a una més gran diversitat per a Android sense necessitat de pagar cap ``peatge'' addicional de desenvolupament. 

\subsection{SL4A}

La solució que planteja SL4A va una mica més enllà que la ``simple'' compilació creuada, tot i que no és una idea radicalment diferent. 

\paragraph{}
Scripting Layer for Android (SL4A) intenta portar els llenguatges de programació de scripts a Android permetent editar i executar scripts i intèrprets interactius directament en un dispositiu Android. Aquests scripts tenen accés a moltes de les APIs disponibles per a les aplicacions Android normals, però amb una interfície més senzilla que facilita fer les coses més ràpid.

Els scripts poden ser executats interactivament en un terminal, o en segon terme. Actualment SL4A suporta Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, i shell. Però en un futur potser n'apareixen més.

\paragraph{}

Malgrat la bona pinta que feia, SL4A encara esta en estat alfa, i esta dissenyat perquè els que l'utilitzin siguin desenvolupadors de software, així que encara hi ha força ``bugs'' i s'espera que amb el temps millori bastant.

\paragraph{}

El problema més gran que suposa la utilització de SL4A és que existeixen limitacions en el que es pot fer a nivell de pantalla (paradoxalment és una mica el problema invers que apareixia al considerar solucions pensades per crear jocs mitjançant compilació creuada).

\paragraph{}

Una de les API's que no són accessibles als llenguatges de scripting és la de mapes, ni la de gràfics. A més la dificultat de controlar els esdeveniments amb aquesta API pel mig dificulta força la interacció amb els usuaris. 

\subsubsection{Arquitectura}


La idea que hi ha darrere l'SL4A és la següent: Tenir un programa servidor de RPC que tingui accés a les API's de Google i que es posi a escoltar, i per altra banda tenir un intèrpret del llenguatge de programació de scripting compilat per a Android (cross-compiled). En el moment que l'interpret detecti que s'està cridant un mètode destinat a les API's de Google es generarà una crida que mitjançant JSON i RPC transmetrà al servidor les dades de la crida. I així podem invocar un mètode remot.

\paragraph{}

Això significa que, fent un símil entre SL4A i una arquitectura distribuïda en xarxa, el sistema operatiu d'Android seria el servidor i l'script interpretat un client.

\paragraph{}

\begin{figure}[ht]
  \centering
        \includegraphics[width=0.8\textwidth]{misc/sl4a_fig_5-21.eps}
  \caption{Arquitectura de SL4A.}\label{fig-arquitectura-sl4a}
\end{figure}

Al nivell més baix, l'aplicació de SL4A que es proporciona és essencialment un host de scripting, cosa que significa que com a aplicació té diferents intèrprets cadascun dels quals per a un llenguatge específic. Aquests intèrprets han estat compilats per a la arquitectura ARM fent servir l'NDK i es carreguen com a una biblioteca quan l'SL4A s'executa un interpret especific.


A partir d'aquí l'script serà interpretat seqüencialment línia a línia normalment. 

\paragraph{}

Però, el truc és que cada script ha d'importar un fitxer (en el cas de Python és android.py) que defineix una serie de funcions necessàries per comunicar-se, mitjançant RPC (remote procedure calls) i JSON (JavaScript Object Notation), amb les ``Facanes'' de SL4A.
Aquestes façanes al seu temps es poden comunicar amb les API d'Android.

\paragraph{}

Quan l'script s'ha iniciat, també se li ha donat, a part de la seva pròpia instància de l'intèrpret (i una pantalla de text, en cas de no haver estat iniciat en segon pla), també se li proporciona, deia, una connexió TCP amb el servidor re RPC de SL4A.


De fet, el servidor de RPC de SL4A el que fa és obrir un socket, i escoltar peticions entrants, que seran les crides a les apis de Google encapsulades amb JSON.


I pel que fa l'script, en el moment que intenti fer una crida a una de les APIs de Google (per exemple si fem un android.makeToast()), el codi addicional que hem inclòs agafarà (catch) l'excepció que es genera (ja que es tracta d'un mètode desconegut) i en comptes de propagar aquesta excepció passarà el mètode cridat (junt amb els paràmetres corresponents) al servidor RPC com a una petició JSON. 


Després aquesta petició serà processada i el resultat es passa de tornada cap a l'intèrpret i a l'script que s'està executant.


Aquesta estructura fa que l'script no necessiti tenir cap coneixement de quina versió de SL4A està essent executada. I a més, aquest nou nivell d'abstracció entre SL4A i el sistema també serveix per prevenir que algun script maliciós pugui arribar a fer mal al sistema.

\paragraph{}

A continuació podeu veure un diagrama de flux que representa l'execució d'un script Python, i on es veu la interacció dels diferents mòduls i parts de SL4A.

\paragraph{}

\begin{figure}[ht]
  \centering
        \includegraphics[width=0.8\textwidth]{misc/sl4a_fig1.1_execution_flow_diagram.eps}
  \caption{Flux d'execució de SL4A.}\label{fig-flux-execucio-sl4a}
\end{figure}

%\subsubsection{Features}

\FloatBarrier
\section{Conclusió}

Després de fer aquest estudi aquestes són les conclusions a que es pot arribar pel que fa a solucions existents, i a la plataforma en concret que s'ha estudiat.

\paragraph{}
Pel que he pogut comprovar, el procediment normal que plantegen les aplicacions per a treballar amb mapes en dispositius mòbils sol ser assumir que existeix connexió de xarxa i descarregar sota demanda imatges de mapes processades en servidors externs.

\paragraph{}
Algunes aplicacions consideren la possibilitat que no es tingui connexió a la xarxa, i les propostes que fan per solucionar aquesta inconveniència són emmagatzemar al dispositiu la informació que serveixen els servidors en forma de tessel·les (imatges) que consumeixen molt d'espai al dispositiu, o, en el millor dels casos processar aquestes dades en un ordinador personal i copiar-les al telèfon per al seu ús fora de línia més endavant. 

\paragraph{}
Renderitzar els mapes directament al telèfon sembla desitjable quan no es té connexió. Això permetria descarregar només la informació ``vectorial'' dels mapes al dispositiu (molt menys voluminosa) i ``pintar-la'' només quan es vulgui mostrar per pantalla.

Però aquesta no sembla ser una opció gaire estesa. Els motius poden ser la alta disponibilitat de xarxes al telèfons. O la relativa limitada capacitat de càlcul que aquests dispositius tenien fins fa poc (sobretot tenint en compte que càlculs intensius poden consumir molta bateria del telèfon i el sistema convida a evitar-los). També pot ser la creixent capacitat de memòria dels telèfons, que fa que guardar els mapes com a imatges en els dispositius no arribi a ser tant dramàtic.

\paragraph{}
En qualsevol cas, considerant el gran increment en la capacitat de càlcul dels telèfons dels darrers temps, semblava que es podria intentar trobar algun mecanisme per assolir aquesta funcionalitat pel present projecte.

\paragraph{}
En quant a les conclusions de l'estudi pel que fa a Android pròpiament, després d'haver estudiat tantes alternatives interessants un s'adona de les dimensions que ha abastat la plataforma Android. Tant a nivell de varietat d'aplicacions com de documentació existent. És realment aclaparador, fins i tot en un camp tant aparentment especialitzat com el que s'estava estudiant.

\paragraph{}
Així queda palesa la grandària de la comunitat de desenvolupadors que han vist possibilitats en Android i treballen amb aquesta plataforma. 

Segurament això és fruit de la idoneïtat dels dispositius mòbils actuals per realitzar tasques relacionades amb els sistemes GIS, i també hi ha ajudat, probablement, la relativa ``novetat'' del sistema i el gran nombre d'usuaris que actualment te. Però malgrat això no esperava trobar tanta cosa.

Com a contrapartida també he pogut comprovar alguns aspectes negatius que comporta la evolució tant ràpida en una plataforma, que fa que els projectes apareguin i siguin abandonats a gran velocitat, o torna obsolets dispositius o solucions molt de pressa.

A més l'estudi també ha servit per comprovar que cap de les solucions existents en el sistema Android satisfeia els objectius del projecte. I també s'ha vist que els intents de portar les alternatives d'altres sistemes (principalment sistemes GNU/LINUX) no havien estat reeixits fins al moment, deixant entreveure que malgrat tractar-se d'un sistema ``parcialment lliure'' les seves particularitats dificultaven la tasca de portar codi d'altres plataformes a Android.

\paragraph{}
Com a apunt final de l'estudi he de reiterar que m'ha sorprès la quantitat de projectes existents en Android, tant en el camp dels sistemes GIS com en el sector de modificacions del sistema o alternatives per a programar-hi en altres llenguatges de programació he anat trobant un gran nombre de treballs, molts dels quals no tenien relació directa amb el present projecte i no han estat inclosos a l'estudi, però han deixat una sensació molt forta d'enormitat.

\paragraph{}
Estic segur que mentre escric aquestes línies algú està desenvolupant alguna aplicació o biblioteca que estigui relacionada amb aquest PFC, i que hauria pogut ser estudiada i potser, fins i tot, aprofitada per les finalitats del present projecte. Però també cal saber quan abandonar l'etapa de recerca i, treballant amb els coneixements adquirits, aplicar-los per crear una bona solució. 
